The cascade deletion at line 1496 uses this.adminforth.resource(childRes.resourceId).delete(childRecord[childPkFieldName]), which calls OperationalResource.delete() → connector.deleteRecord() directly, completely bypassing:

1. The resource's delete hooks (hooks.delete.beforeSave and hooks.delete.afterSave)
2. Permission checks (allowedActions.delete) for the child resource

This is a critical concern because these hooks are often used for cleanup of related artifacts (e.g., file storage cleanup in upload plugins, as referenced by the warning in the connector code). Additionally, the setNull path at line 1500 has the same issue — this.adminforth.resource(childRes.resourceId).update() similarly bypasses edit hooks for child records.

To trigger hooks and permissions, the implementation should use this.adminforth.deleteResourceRecord(...) for cascade deletions and this.adminforth.updateResourceRecord(...) for setNull operations, similar to how the parent record deletion is handled at line 1506.

At line 1487, childRes.columns.find(...) only returns the FIRST column in the child resource that has a foreignResource.resourceId matching the parent. If a child resource has multiple columns referencing the same parent resource (e.g., created_by and updated_by both pointing to users), only the first matching column will have its cascade/setNull strategy applied. The second FK column will be silently ignored.

Consider using childRes.columns.filter(...) to get all FK columns pointing to the parent resource, and then iterating over each one.

The MySQL query uses WHERE kcu.REFERENCED_TABLE_NAME = ? and selects kcu.COLUMN_NAME, which returns column names from CHILD tables that reference the current table (i.e., columns in other tables that point to this table as a parent). This is the opposite perspective from the SQLite implementation, which uses PRAGMA foreign_key_list(tableName) to return FK columns defined ON the current table (the child side).

The practical effect is that in MySQL, fkMap keys are column names from child tables rather than columns of the current table being discovered. For the warning logic this is functionally harmless since the warning fires as long as any cascade is found. However, it is semantically inconsistent with the SQLite approach and with the intent of discoverFields (which is supposed to characterize the fields of the current table). If fkMap is later used to set field properties (similar to SQLite's field.cascade = fkMap[row.name] || false), this inverted mapping would cause incorrect results.

SQLite's PRAGMA foreign_key_list(tableName) returns the FK constraints defined in tableName — i.e., where tableName is the child/dependent table. So fkMap[fk.from] maps columns in the current table that reference other (parent) tables, and checks if they have ON DELETE CASCADE.

However, the warning aims to detect conflicts where a child table targeting the current (parent) resource already has a DB-level ON DELETE CASCADE — which would double-delete when adminForth's cascade deletion also runs. To detect that conflict correctly, you need to check tables that reference the current table as their parent (the reverse direction).

In contrast, the PostgreSQL and MySQL queries correctly filter by the current tableName as the referenced/parent table and find child tables that cascade-delete on the current table's row deletion.

The SQLite check should use a different approach to detect child tables that reference the current table with ON DELETE CASCADE (e.g., check PRAGMA foreign_key_list on all other discovered tables and look for references to the current table).

The fkMap returned from getPgFkCascadeMap is keyed by column_name from child tables (not the current table being discovered). When multiple child tables reference the current table using differently-named columns (e.g., child_a.user_id and child_b.user_id), the last write would overwrite the earlier entry. However, since the map is only used to check if any cascade exists (line 112), collisions don't affect correctness of the warning. But the map itself contains misleading data — it represents child-table FK columns, not the current table's own columns — and the variable naming (targetTable refers to the parent, not the child) adds to the confusion. The entire fkMap structure is unnecessary; since only the cascade boolean is needed for the warning, a simpler Set<string> or direct boolean flag would be cleaner.

deleteWithCascade ignores the return value of deleteResourceRecord (line 189), which returns { error: string | null }. If a beforeSave hook returns an error or the DB delete fails, the error is silently discarded. Callers of deleteWithCascade (including the delete_record endpoint and the bulk delete action) have no way to know whether deletion actually succeeded.

The method signature should return a result indicating success/failure (e.g., Promise<{ error: string | null }>), and callers should check the returned error and halt the operation if one is present. In the cascade case (line 178), if a child deletion fails, the parent should not be deleted.

this is important

Maybe better is to tell something to user?
Or do it like was just return

Similar to the MySQL connector, the Postgres fkMap built in getPgFkCascadeMap (lines 97–105) is used only to emit the hasCascade warning (lines 112–115) and is never used to set a field.cascade property on individual discovered fields. The SQLite connector sets field.cascade per field, but Postgres does not, leading to an inconsistency across connectors.

The deleteWithCascade method (line 191) already calls this.adminforth.deleteResourceRecord(...) internally, which performs the actual DB deletion and runs both beforeSave and afterSave delete hooks. Then, immediately after calling deleteWithCascade at line 1523, deleteResourceRecord is called again at lines 1525–1528 for the same parent record.

This causes two problems:

1. The parent record is deleted twice — the second deletion either silently no-ops or throws a "record not found" error.
2. Both beforeSave and afterSave delete hooks fire twice for the parent resource.

The fix is to remove the redundant deleteResourceRecord call at lines 1525–1528, since the deletion and hook execution is already handled inside deleteWithCascade.

The MySQL fkMap built at lines 92–101 is keyed on child-table column names (columns from other tables that reference this table), yet it is never used to annotate any field property in the current table's fieldTypes. Only the warning is emitted when cascade is true.

By contrast, the SQLite connector (sqlite.ts line 96) sets field.cascade = fkMap[row.name] || false on each discovered field. The Postgres connector has the same inconsistency — the fkMap from getPgFkCascadeMap is used only for the warning, never to set field.cascade.

If field.cascade is not needed for Postgres and MySQL, the SQLite connector should also drop field.cascade and the logic should be consistent. If field.cascade is needed, the MySQL and Postgres connectors need equivalent per-field annotation.